3 avatar="http://cdn.libravatar.org/avatar/605b2981cb52b4af268455dee7a4f64e"
4 subject="History of change"
5 date="2023-07-12T10:27:43Z"
7 Thanks for the [pointer to the earlier bug discussing changing sync entirely](https://git-annex.branchable.com/todo/Having___39__git_annex_sync__39___optionally_add) @nobodyinperson; it's at least useful to have a reference for where all this breaking change suddenly came from given it's otherwise undocumented. I've added a back pointer comment to that bug pointing at this one, as they're clearly related discussion (and it wasn't obvious the other \"sync\" bug was at all related to the change).
9 I still strongly disagree with changing \"sync\" to do something pretty different from what it's done for 10 years being a good idea. But would certainly support there being *another* command that did a \"Dropbox like full sync\".
11 (Personally I'd really really prefer that \"sync\" stayed doing the same thing it's done for a decade: meta data sync, only. If we're going to have to run a new different command just to retain core \"meta data sync\" behaviour, I guess \"git annex sync --no-content\" is not much worse than any other command we'd have to remember to suddenly use instead starting version N + 1.)